Proxy, Registration and Authentication Parameters

Defines the Home Proxy domain name. If specified, this name is used as the Request-URI in REGISTER, INVITE and other SIP messages, and as the host part of the To header in INVITE messages. If not specified, the Proxy IP address is used instead.

The valid value is a string of up to 49 characters.

Note: The parameter functions together with the UseProxyIPasHost parameter.

Enables the use of the proxy server's IP address (in dotted-decimal notation) as the host name in SIP From and To headers in REGISTER requests.

If the parameter is disabled and the device registers to an IP Group (i.e., proxy server), it uses the string configured by the ProxyName parameter as the host name in the REGISTER's Request-URI and uses the string configured by the IP Groups table parameter, SIPGroupName as the host name in the To and From headers. If the IP Group is configured with a Proxy Set that has multiple IP addresses, all the REGISTER messages sent to these proxies are sent with the same host name.

Note: If the parameter is disabled and the ProxyName parameter is not configured, the proxy's IP address is used as the host name in the REGISTER Request-URI.

Determines whether the device switches back to the primary Proxy after using a redundant Proxy.

Note: To use this Proxy Redundancy mechanism, you need to enable proxy keep-alive (see the [ProxySet_ProxyKeepAliveTime] parameter).

Defines the interval (in seconds) at which the device performs DNS resolution for Proxy Sets that are configured with an FQDN (host name), in order to translate (resolve) it into IP addresses. The device maintains a cache of DNS resolutions, and uses the cached responses as long as the TTL has not expired. If the TTL has expired, a new DNS request is sent to the DNS server.

For example, if configured to 60, the device queries the DNS server every 60 seconds. if successful, the device refreshes the Proxy Set’s list of DNS-resolved IP addresses.

The device caches (stores) the DNS-resolved IP addresses of the last successful DNS query. It clears every entry in the cache 30 minutes after its time-to-live (TTL) value expires. If the DNS server is offline (for whatever reason) when the device performs a DNS query, instead of taking the Proxy Set offline, the device reuses the cached DNS-resolved addresses. In such a scenario, the device continues to query the DNS server every 10 seconds. However, if the DNS server is still offline after the device has deleted the cached DNS-resolved IP addresses, the device takes the Proxy Set offline.

The valid value is 0, or 5 to 2,000,000. The default is 60. The value 0 disables periodic DNS queries and DNS resolution is done only once - upon device reset, device power up, or new and modified configuration.

Determines whether the device sends SIP messages and responses through a Proxy server.

Note: The parameter is applicable only if a Proxy server is used (i.e., the parameter IsProxyUsed is set to 1).

Enables the use of DNS Naming Authority Pointer (NAPTR) and Service Record (SRV) queries to resolve Proxy and Registrar servers and to resolve all domain names that appear in the SIP Contact and Record-Route headers.

Note:

Global parameter that defines the DNS query record type for resolving the Proxy server's configured domain name (FQDN) into an IP address.

Note:

Defines if the device's IP address, proxy's IP address, or device's name is used as the host part for the Request-URI in keep-alive SIP OPTIONS messages sent to the proxy (if enabled). The device uses the OPTIONS messages as a keep-alive with its primary and redundant SIP proxy servers. Proxy keep-alive by SIP OPTIONS is enabled per Proxy Set in the Proxy Sets table, by configuring the [ProxySet_EnableProxyKeepAlive] parameter to [1]). For more information, see Configuring Proxy Sets.

Defines how long the device waits (in seconds) before re-sending a SIP OPTIONS keep-alive message to the proxy once the device considers the proxy as offline (i.e., after all retransmissions, configured by the [ProxySet_FailureDetectionRetransmissions] parameter, have failed).

The valid value range is 1 to 3600. The default is 1.

Note:

When using UDP as the transport protocol, the retries failed transmissions to a proxy server is according to the [ProxySet_FailureDetectionRetransmissions] parameter. However, when the failed attempt receives an ICMP error (which indicates Host Unreachable or Network Unreachable) as opposed to a timeout, it may be desirable to abandon additional retries in favor of trying the next IP address (proxy server) in the Proxy Set. This is often desirable when Proxy Hot Swap is enabled.

Defines the password for Basic/Digest authentication with a Proxy/Registrar server. A single password is used for all device ports.

The default is 'Default_Passwd'.

Note:

Defines the Cnonce string used by the SIP server and client to provide mutual authentication.

The value is free format, i.e., 'Cnonce = 0a4f113b'. The default is 'Default_Cnonce'.

Enables local caching of SIP message authorization challenges from Proxy servers.

The device sends the first request to the Proxy without authorization. The Proxy sends a 401/407 response with a challenge for credentials. The device saves (caches) the response for further uses. The device sends a new request with the appropriate credentials. Subsequent requests to the Proxy are automatically sent with credentials (calculated from the saved challenge). If the Proxy doesn't accept the new request and sends another challenge, the old challenge is replaced with the new one. One of the benefits of the feature is that it may reduce the number of SIP messages transmitted through the network.

Note:

Defines the time interval (in seconds) for registering to a Proxy server. The value is used in the SIP Expires header. The parameter also defines the time interval between Keep-Alive messages when the parameter EnableProxyKeepAlive is set to 2 (REGISTER).
Typically, the device registers every 3,600 sec (i.e., one hour). The device resumes registration according to the parameter RegistrationTimeDivider.

The valid range is 10 to 2,000,000. The default is 180.

Defines the re-registration timing (in percentage). The timing is a percentage of the re-register timing set by the Registrar server.

The valid range is 50 to 100. The default is 50.

For example: If the parameter is set to 70% and the Registration Expires time is 3600, the device re-sends its registration request after 3600 x 70% (i.e., 2520 sec).

Note: The parameter may be overridden if the parameter RegistrationTimeThreshold is greater than 0.

Defines the time interval (in seconds) after which a registration request is re-sent if registration fails with a 4xx response or if there is no response from the Proxy/Registrar server.

The default is 30 seconds. The range is 10 to 3600.

Note: Registration retry time can also be configured with the MaxRegistrationBackoffTime parameter.

Defines a dynamic time-to-wait interval before the device attempts to register the SIP entity again after a registration failure. The parameter is applicable only to registrations initiated by the device on behalf of SIP entities (for example, User Info, Accounts, Endpoints or the device itself) with a SIP proxy server (registrar).

The valid value is 0 to 3000000 (i.e., 3 million seconds). The default is 0 (i.e., disabled).

In contrast to the RegistrationRetryTime parameter, which defines a fixed time to wait between registration attempts due to registration failure, this parameter configures the device to increase the time-to-wait interval for each subsequent registration attempt (per RFC 5626, Section 4.5) for a specific registration flow. In other words, the interval changes between registration attempts.

The parameter operates together with the RegistrationRetryTime parameter. When the MaxRegistrationBackoffTime parameter is configured, the wait-time before another registration attempt increases after each failed registration (until it reaches the maximum value specified by the parameter).

The device uses the following algorithm to calculate the incremental augmented wait-time between each registration attempt:

Wait Time = min (max-time, (base-time * (2 ^ consecutive-failures)))

Where:

For example, if max-time is 1800 seconds and base-time is 30 seconds, and there were three consecutive registration failures, then the upper-bound wait time is the minimum of (1800, 30*(2^3)), which is (1800, 240) and thus, the minimum of the two values is 240 (seconds). The actual time the device waits before retrying registration is computed by a uniform random time between 50% and 100% of the upper-bound wait time (e.g., for an upper-bound wait-time of 240, the actual wait-time is between 120 and 240 seconds). As can be seen from the algorithm, the upper-bound wait time can never exceed the value of the MaxRegistrationBackoffTime parameter.

Defines a threshold (in seconds) for re-registration timing. If the parameter is greater than 0, but lower than the computed re-registration timing (according to the parameter RegistrationTimeDivider), the re-registration timing is set to the following: timing set by the Registration server in the SIP Expires header minus the value of the parameter RegistrationTimeThreshold.

The valid range is 0 to 2,000,000. The default is 0.

Enables the device to perform SIP re-registration upon TCP/TLS connection failure.

Enables the device to allow FXS endpoints (ports) to make emergency calls (Tel-to-IP) even if registration of a specific port to the SIP proxy server has failed (for whatever reason, for example, payment required). This feature applies to all FXS endpoints, including ports configured for automatic dialing in the Automatic Dialing table (see Configuring Automatic Dialing).

When an FXS analog phone connected to a port that has failed registration, goes off-hook, the device plays a reorder tone to the port, indicating to the end user that the service is unavailable. However, the end user can still place emergency calls (or calls to any of the user-defined emergency numbers). These calls go through the same IP destination (i.e., proxy server).

Note:

Enables the device to perform explicit unregisters.

Note: The REGISTER-specific Contact header field value of "*" applies to all registrations, but it can only be used if the Expires header field is present with a value of "0".

Enables the inclusion of the SIP Authorization header in initial registration (REGISTER) requests sent by the device.

The Authorization header carries the credentials of a user agent (UA) in a request to a server. The sent REGISTER message populates the Authorization header with the following parameters:

For example:

Authorization: Digest username=alice_private@home1.net, realm=”home1.net”, nonce=””, response=”e56131d19580cd833064787ecc”

Note: This registration header is according to the IMS 3GPP TS24.229 and PKT-SP-24.220 specifications.

Enables the inclusion of the SIP Route header in initial registration or re-registration (REGISTER) requests sent by the device.

When the device sends a REGISTER message, the Route header includes either the Proxy's FQDN, or IP address and port according to the configured Proxy Set, for example:

Route: <sip:10.10.10.10;lr;transport=udp>

or

Route: <sip: pcscf-gm.ims.rr.com;lr;transport=udp>

Enables the use of the carriage-return and line-feed sequences (CRLF) Keep-Alive mechanism, according to RFC 5626 “Managing Client-Initiated Connections in the Session Initiation Protocol (SIP)” for reliable, connection-orientated transport types such as TCP.

The SIP user agent/client (i.e., device) uses a simple periodic message as a keep-alive mechanism to keep their flow to the proxy or registrar alive (used for example, to keep NAT bindings open). For connection-oriented transports such as TCP/TLS this is based on CRLF. This mechanism uses a client-to-server "ping" keep-alive and a corresponding server-to-client "pong" message. This ping-pong sequence allows the client, and optionally the server, to tell if its flow is still active and useful for SIP traffic. If the client does not receive a pong in response to its ping, it declares the flow “dead” and opens a new flow in its place. In the CRLF Keep-Alive mechanism the client periodically (defined by the PingPongKeepAliveTime parameter) sends a double-CRLF (the "ping") then waits to receive a single CRLF (the "pong"). If the client does not receive a "pong" within an appropriate amount of time, it considers the flow failed.

Note: The device sends a CRLF message to the Proxy Set only if the Proxy Keep-Alive feature (EnableProxyKeepAlive parameter) is enabled and its transport type is set to TCP or TLS. The device first sends a SIP OPTION message to establish the TCP/TLS connection and if it receives any SIP response, it continues sending the CRLF keep-alive sequences.

Defines the periodic interval (in seconds) after which a “ping” (double-CRLF) keep-alive is sent to a proxy/registrar, using the CRLF Keep-Alive mechanism.

The default range is 5 to 2,000,000. The default is 120.

The device uses the range of 80-100% of this user-defined value as the actual interval. For example, if the parameter value is set to 200 sec, the interval used is any random time between 160 to 200 seconds. This prevents an “avalanche” of keep-alive by multiple SIP UAs to a specific server.

Defines the maximum number of user register requests (REGISTER messages) that the device sends (to a proxy or registrar server) at a user-defined rate configured by the GeneratedRegistersInterval parameter. The parameter is useful in that it may be used to prevent an overload on the device's CPU caused by sending many registration requests at a given time.

The valid value is 30 to 300 register requests per second. The default is 150.

For configuration examples, see the description of the GeneratedRegistersInterval parameter.

Defines the rate (in seconds) at which the device sends user register requests (REGISTER messages). The parameter is based on the maximum number of REGISTER messages that can be sent at this rate, configured by the MaxGeneratedRegistersRate parameter.

The valid value is 1 to 5. The default is 1.

Configuration examples:

Defines SIP response codes that if received for a failed INVITE message sent for an Account, triggers the device to re-register the Account. The parameter is applicable only if the Account's 'Re-Register on Invite Failure' parameter in the Accounts table is configured to Enable (see Configuring Registration Accounts).

The valid value is a SIP response code. Multiple response codes can be configured, where each value is separated by a comma. The default is "403,408,480" (without quotation marks).

Note: SIP response code 408 also refers to an INVITE timeout (i.e., no reply from server). Therefore, if re-registration is needed for such a scenario, make sure that you configure the parameter with "408" as well.

Defines a graceful time (in seconds) which is intended to prevent the device from sending REGISTER requests to a registrar server where the device previously registered, if the device also registered successfully to another server since the last successful registration to the registrar server. This can occur if the registrar server has been offline for a brief time. For more information, see the 'Registrar Search Mode' parameter in Configuring Registration Accounts.

The valid value is 0 to 15.2 million. The default is 0.

Enables the device to retry registering even if the last SIP 401\407 response included "stale=false".

When the device initiates a REGISTER request with an Authorization header (according to the relevant configured credentials), and it receives a SIP 401\407 response with the stale parameter set to "false", by default the device doesn't try to send another REGISTER message. When the parameter is enabled, the device retries registering even if the last 401\407 response had "stale=false".

Note: This parameter is applicable only to REGISTER requests which the device initiates (e.g., for an Account or for Gateway endpoints); it's not for REGISTER requests that the device forwards from the user to the registrar server.